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Abstract 


On August 8, 2009, a private airplane collided with a sightseeing helicopter over the Hudson River near Hoboken, 
New Jersey. All three people aboard the airplane, the pilot and two passengers, and all six people aboard the 
helicopter, the pilot and five passengers, were killed. The National Transportation Safety Board report on the 
accident identified inherent limitations of the see-and-avoid concept, inadequate regulations, and errors by the pilots 
and an air traffic controller as causing or contributing to the accident. This paper presents the results of analyzing 
the accident using the Systems-Theoretic Accident Model and Processes (STAMP) approach to determining 
accident causation. 


Introduction 


The Langley Aerospace Research Student Scholars (LARSS) program provides internship opportunities at the 
NASA Langley Research Center in Hampton, Virginia for undergraduate and graduate students pursuing degrees in 
science, technology, engineering, and mathematics. The program is “designed to bridge the gap between academic 
concepts and real-world experience, by creating opportunities for students to come to NASA Langley Research 
Center to conduct research and work on projects under the mentorship of NASA professionals” (ref. 1). 

In the summer of 201 1, the first author participated in the LARSS program as a rising third-year student in systems 
engineering at the University of Virginia; the second author was his mentor. During his 10-week internship the 
student applied Systems-Theoretic Accident Model and Processes (STAMP) to analyze a 2009 midair collision 
between a private airplane and a sightseeing helicopter. Besides providing the student with a realistic and 
interesting project, the case study had two objectives: (1) to determine whether the existing literature on STAMP 
was sufficient to enable someone to use the model without prior training; and, if so, (2) to evaluate benefits of the 
model. The case study was not intended to, nor did it, reinvestigate the accident or question any of the factual 
statements made in the official investigation. This paper describes the results of the project in four parts. First, an 
overview of STAMP is given. Second, a narrative of the accident is presented. Third, selected excerpts from the 
STAMP analysis are explained. Fourth, and finally, the extent to which the case study achieved its objectives is 
evaluated. 


Overview of STAMP 


STAMP is a model of accidents based on control and systems theory concepts. It was first described publicly in two 
papers presented at the 20 th International System Safety Conference in Denver, Colorado in 2002 (refs. 2, 3). In the 
years since the initial unveiling, the model has been refined and applied to a variety of accidents across many 
domains. STAMP is fully explained and illustrated in a recent book by its creator. Professor Nancy Leveson from 
the Massachusetts Institute of Technology (ref. 4). The overview provided here is necessarily simplified and 
incomplete, but it should be sufficient as a basis for the reader to be able to understand the remainder of the paper. 

In many accident models, the most basic concept is an event; in STAMP the most basic concept is a constraint. 
Accidents are considered to happen because one or more safety-related constraints on system behavior are not 
successfully enforced. Enforcing safety constraints (and thus avoiding accidents) is considered a dynamic control 
problem. Thus, systems are modeled as hierarchical control structures, consisting of connected individual simple 
control structures as shown in Figure 1. 

The right-hand side of the figure shows an expanded view of an individual control structure within the hierarchy. 
The controller is responsible for enforcing constraints on its controlled process by issuing appropriate control 
actions, based on feedback from the controlled process, the controller’s internal process model, and the control 



algorithm. A controller may be hardware, software, human, or some combination of the three. STAMP applies 
equally well to all of these possibilities, and uses the same generic term “controller” in all cases. All of the other 
elements of the model (actions, feedback, process model, and algorithm) also may consist of hardware, software, 
humans, or combinations of the three. 

A canonical example of a simple control system is a thermostat. Loosely speaking, the constraint enforced by a 
thermostat is something like “The temperature must stay within a certain range of the desired temperature.” The 
feedback received is the current temperature in the room, and the control actions issued are commands to the heating 
or air conditioning unit to remain idle, distribute heated air, or distribute cooled air. Determining which of these 
commands to issue is a function of the feedback received about the current temperature and the algorithms 
implemented for altering the temperature. A modern thermostat is likely to be implemented primarily in software; 
older thermostats were primarily hardware devices. Although it may seem odd to use the term ‘thermostat’ for such 
a situation, a human waving a fan can be thought of as another instantiation of the same control loop. 
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Figure 1 — STAMP’S hierarchical control structure model 

Most real systems are significantly more complex than a simple thermostat. Modeling such systems requires more 
than one controller / controlled process element. An individual element may function as the controller in one level 
and as the controlled process in another level. Also, besides just control actions and feedback, other types of 
communications may take place among elements. The left-hand side of Figure 1 shows an example of such a 
hierarchical control structure. The dashed line represents communication that does not involve control or feedback. 

By modeling systems in this way, causal factors for accidents can be classified into three general categories: (1) 
controller operation, (2) behavior of controlled processes, and (3) communication and coordination among 
controllers. These categories may be sub-divided further. For example, accidents that happen as a result of 
controller operation will involve one or more unsafe inputs, unsafe control algorithms, or flawed process models. 
Flawed process models may be inconsistent, incomplete, or incorrect. These flaws may have been present from the 
beginning in the design of the system, or they have developed over time from, for example, missing, incorrect, or 
delayed feedback. Considering these various possible categories of causal factors provides a convenient and 
powerful way to develop an understanding of why an accident happened. 


Several possible approaches may be taken in using STAMP to analyze a particular accident. In the next section, we 
provide a narrative description of the specific accident to which one of those approaches was applied in the intern 
project. After the narrative, we describe selected results from the analysis. 

The Accident 


The accident analyzed for the project happened on August 8, 2009, over the Hudson River, near Hoboken, New 
Jersey Shortly before noon, a private airplane collided with a sightseeing helicopter, killing everyone aboard the two 
aircraft (a pilot and two passengers in the airplane; a pilot and five passengers in the helicopter). The National 
Transportation Safety Board (NTSB) investigated the accident and produced a report, which was approved at a 
public Board meeting on September 14, 2010. The published report (ref. 5) is the basis for the narrative description 
in this section, and served as the source material for the STAMP analysis described in the next section. Figure 2 
reproduces a map of the area, annotated with the routes flown by the accident aircraft. 
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Figure 2 — Approximate routes of the aircraft (based on ref. 6) 

The accident airplane was a Piper PA-32R-300. The accident helicopter was a Eurocopter AS350BA. Both flights 
operated under the relevant Code of Federal Regulations (CFR) parts: 14 CFR Part 91 for the airplane, and 14 CFR 
Parts 135 and 136 for the helicopter. Good weather allowed visual meteorological conditions to prevail before and at 
the time of the accident. Neither flight required a flight plan. The pilot of the Piper was flying from Wings Field 
Airport, Philadelphia, Pennsylvania, to Ocean City Municipal Airport in New Jersey. He stopped at Teterboro 
Airport (TEB) in New Jersey to pick up a passenger. The pilot of the Eurocopter departed with his five passengers 
from the West 30 th Street Heliport (JRA) in New York, New York, on a local sightseeing flight. 


When preparing to leave TEB at about 1 1 :40 a.m. the pilot of the Piper contacted the TEB air traffic control tower. 
The pilot received taxi instructions from the TEB controller 1 . The controller asked the pilot which route he planned 
to take to Ocean City. After a brief exchange with the controller, the pilot decided he would travel down the Hudson 
River. This choice of route required the pilot to contact controllers at Newark Liberty International Airport (EWR) 
after the flight was transferred from TEB to EWR. This contact was for the purpose of obtaining authorization to 
climb into Class B airspace after transiting the Hudson River Class B exclusion area 2 . Before takeoff the pilot asked 
the TEB controller for traffic advisories throughout his flight; afterwards the controller cleared him for takeoff. The 
controller directed the pilot where to turn after takeoff and informed him of a helicopter (not the accident helicopter) 
in his vicinity. 

About two minutes after clearing the Piper for takeoff, the TEB controller started a personal phone call. While on 
the phone he directed the Piper pilot to turn towards the Hudson River; he did not advise the pilot to self-announce 
the airplane’s position on the common traffic advisory frequency. The TEB controller did not violate any rules in 
place at the time by not providing this advice. 

While still on the telephone at about 1 1 :42 a.m. the TEB controller told the Piper pilot to contact the EWR Air 
Traffic Control Tower on a frequency of 127.85 megahertz. The pilot read back the frequency incorrectly, but this 
mistake was not recognized. No further communications occurred between the TEB controller and the accident 
aircraft. The TEB controller did communicate with the EWR Class B airspace controller, who asked him to transfer 
communications for the flight (an action that the TEB controller had already performed), and to give the airplane a 
heading change to avoid traffic over the Hudson River. 

The accident helicopter was a local sightseeing flight. The helicopter departed from West 30th Street Heliport 
(JRA) at 11:52 a.m. for a tour that was planned to climb across the Hudson River at an altitude of 1,000 feet and 
follow the river towards the Statue of Liberty. Because of the location of the heliport and the planned tour route, the 
pilot was not required to contact ATC. According to radar data, the helicopter’s route took it to the west side of the 
Hudson River, where it turned to follow the river southward, and climbed to an altitude of 1,100 feet. 

The Piper and Eurocopter collided at a few seconds after 11:53 a.m. at an estimated altitude of 1,100 feet 3 . At the 
time of the collision the airplane was traveling at a groundspeed of 150 knots and the helicopter was traveling at 
about 93 knots. After colliding, the two aircraft fell into the Hudson River. According to radar data, conflict alerts 
for the accident airplane and another aircraft were generated 11 times during a time period beginning about 40 
seconds before and ending about 10 seconds after the collision. Although according to the data these alerts were 
generated to both the TEB local controller and the EWR Class B airspace controller, neither controller remembered 
hearing or seeing any of these alerts. 


STAMP Analysis 

The STAMP analysis of the accident was conducted based on the approach illustrated in Chapter 5 of reference 4. 
The accident report was, as noted above, the primary source of information about the accident, but other available 
sources were also consulted (refs. 6-9). The information contained in these sources about rules, regulations, 
procedures, and events was assumed to be correct. 

Hierarchical control structure : The first step of the analysis was to determine an appropriate hierarchical control 
structure associated with the accident (Figure 3). The Federal Aviation Administration (FAA) is placed at the top of 
the hierarchy, because it establishes the rules, regulations, and procedures that control operations within the national 
air space. Beginning with the FAA at the top level was a practical decision. In reality, the FAA itself is part of the 
US Department of Transportation (DOT), and thus has levels of control above it. DOT is not at the true top either. 


1 The word ‘controller’ is necessarily overloaded in the paper. Determining whether the word refers to the STAMP 
concept or to a specific human (or perhaps to both) depends on the context of a particular sentence. 

2 Readers interested in detailed information about the different classes of airspace should consult (ref. 5). 

3 The NTSB concluded that the uncertainty in the altitude was 50 feet, meaning that the collision may have occurred 
at an altitude as low as 1,050 feet or as high as 1,150 feet. They also noted that the investigation was unable to 
determine what the helicopter’s altitude would have ultimately been had the collision not happened. 



as it is subject to the President and Congress, and so on. The TEB air traffic control tower (ATC), Newark (EWC) 
ATCT, JRA Heliport, Piper pilot, and Eurocopter pilot all were, in STAMP terminology, controlled processes 
beneath the FAA. The Eurocopter and Piper pilots were also subject to the FAA directly. The Piper pilot 
additionally was subject to control input from the TEB local controller; if everything had gone as designed, he also 
would have been subject to direction from the EWR Class B airspace controller. 

Within the TEB ATCT, the TEB local controller was beneath the TEB front line manager within the hierarchy. In 
addition to the control channels, communication channels were in place between the TEB local controller and the 
EWR Class B airspace controller. The system also was predicated on the assumption of visual communication 
between the Piper and Eurocopter pilots. That is, under the visual flight rules in affect in the airspace at the time of 
the accident, these two pilots were expected to be able to see and avoid one another. 
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Figure 3 — Control structure for the accident 


Safety Requirements and Constraints : The second step of the analysis was to determine for each entity within the 
hierarchical control structure all of the relevant safety constraints the entity was supposed to enforce and to satisfy. 
These constraints are grouped into three categories below: FAA, air traffic controllers, and pilots. 


FAA: The primary safety constraint the FAA is intended to enforce is continuous adequate separation between 
aircraft. This enforcement is primarily through the rules, orders, and procedures that the agency establishes. 


Air traffic control: FAA Order 7210.3, paragraph 2-6-1, states that watch supervision includes managing the 
operational environment with a goal of eliminating distractions, as well as making on-the-spot corrections. FAA 
Order 7110.65 requires that controllers be fully engaged in their duties. Under this order controllers are also 
expected to instruct pilots with step-by-step routing directions when he/she requests them and the controller’s 



workload situation permits. TEB Order 7110.10 says that if an operational supervisor leaves premises they must 
delegate controller-in-charge responsibilities to a specialist before leaving. FAA Orders 7210.3 and 7210.56 require 
active supervision and oversight. 

Pilots: The most important safety constraint for a pilot is the see-and-avoid concept. FAA advisory circular (AC) 
90-48C (“Pilots’ Role in Collision Avoidance”) states that the see-and-avoid notion requires vigilance at all times by 
each person operating an aircraft regardless of whether the flight is conducted under instrument flight rules (IFR) or 
visual flight rules (VFR). It requires pilots to be constantly alert to all traffic movement within their sight; they 
should scan the entire visual field outside of their aircraft. Another safety requirement for pilots is the use of 
electronic traffic advisory systems, such as traffic information systems (TIS), to complement the see-and-avoid 
concept. They should not rely solely on either system alone. The sightseeing tour operator’s procedures and the 
FAA-approved air tour safety plan constrained the helicopter pilot to operate his vehicle at or below 1,000 feet 
altitude. 

Controls : The third step of the analysis was to enumerate the existing controls that were intended to enforce the 
safety constraints. The controls put in place by the FAA were the rules and regulations regarding the Hudson River 
Class B exclusion area, the training provided to both pilots and air traffic controllers, and the approved assistance 
technology inside of the aircraft. The intended controls for the air traffic controllers and pilots included the pilots’ 
training, air traffic controller’s training, air traffic control tower oversight, radio communication between pilots and 
ATC, the traffic information system, and the Hudson River Class B exclusion area procedures. 

Roles and Responsibilities : The fourth step was to examine the specific roles and responsibilities each of the 
various entities had within the overall control structure. 

FAA: The FAA’s number one responsibility is to ensure that the air is a safe place to travel and that aircraft can fly 
accident-free. To fulfill this responsibility, the agency must establish appropriate rules and regulations and seek to 
make certain that airports, air traffic control towers, pilots, and passengers follow these rules and regulations 
correctly. 

Air Traffic Controllers: Controllers are responsible for assisting and guiding aircraft in the air safely. They are 
responsible for providing constant advisory reports when a pilot asks for them, and for transferring communications 
between a pilot and another ATC in a timely manner. Controllers should be focused on the planes they are 
monitoring and listening to everything a pilot says to them. Front line managers are responsible for overseeing all of 
the controllers in their purview, and for correcting behavior that is inappropriate. The front line manager is 
responsible for letting the rest of the tower know where he can be located in case of an emergency, and for making 
sure there are always enough people working at a given time. 

Piper pilot: The pilot was flying a personal, non-commercial flight but he was still responsible for following FAA 
rules and regulations. The pilot was to stay in communication with the controller and to switch frequencies as 
directed to communicate with the controller at his destination. He also was responsible for using the TIS to assist 
him in knowing what aircraft were in his vicinity, while also physically looking to seek and avoid nearby aircraft. 

Eurocopter pilot: This pilot was giving a tour of the Hudson River area. He was responsible for making sure that 
his passengers were safe and that they were following all of the safety rules. He was also required to follow 
company rules and procedures for giving tours, and for using TIS while looking and avoiding possible aircraft in the 
area. 

Behavior-Shaping Factors : The fifth step undertaken in the analysis was to consider the context within which the 
various elements functioned, looking particularly for factors that may have influenced the behavior of those 
elements. This step concentrated on the air traffic control tower and the pilots, considering that evaluation of 
behavior-shaping factors on the FAA was outside the reasonable scope of a student intern project. 

Air Traffic controllers: The controller who was responsible for the Piper airplane flight became distracted from his 
duties once he took a personal call while communicating with the pilot. The front line manager of the tower should 
have been supervising his controllers and noticed this inappropriate behavior. It could have been corrected but since 



it was not, the controller took another call a few minutes after his first telephone conversation. The front line 
manager left the tower without leaving contact information and he did not effectively delegate tasks before he left. 

Piper pilot: The pilot did not anticipate flying in the Hudson River Class B exclusion area. He had to fly in an 
unfamiliar airspace and he did not know the standard procedures for the area. The pilot was unaware that he should 
have announced his presence over the radio. This would not have been an issue if the controller had continued 
giving him the advisories for which he had asked. Because the controller did not give him any advisories, the pilot 
may have reasonably believed that the area was clear of traffic. If he did believe the area was traffic free, then he 
most likely did not think he had to regularly seek and avoid traffic. The helicopter was on his left against a city 
background; this background would have made it very difficult for the pilot to spot the helicopter until it was very 
close. Figure 4 shows selected results from the NTSB’s cockpit visibility study, which simulated the views that 
were available to the Piper pilot in the seconds before the accident. 

Eurocopter Pilot: The pilot was being a tour guide while simultaneously flying; this may have caused him to be less 
aware of his surroundings. 



1 second before collision 


Figure 4 — Simulated views from Piper cockpit (refs. 5,8) 

Inadequate Control Actions & Interactions : The sixth step undertaken in the analysis was to identify the inadequate 
control actions that were taken, along with any dysfunctional interactions among control elements that took place. 
Some of those that were identified in the project are listed below. 

FAA: The rules in place at the time of the accident recommended, but did not require, that pilots self-announce their 
entrance into the Class B exclusion area over the common traffic advisory frequency. Nor did the rules and 
procedures clearly provide adequate vertical separation between aircraft operating in this area. 



TEB Front Line Manager: The manager left the tower without providing information about how he could be reached 
if needed. He did not adequately provide for supervision during his absence. He also permitted without correction 
the local controller to conduct personal phone calls while on duty. These actions were not consistent with 
procedures established to ensure that the relevant safety constraints were enforced. 

TEB Local Controller: The controller delayed the transfer of communications to the EWR Class B airspace 
controller. He took two phone calls while still communicating with the Piper pilot. He did not provide continual 
traffic advisories to the pilot, despite his workload being sufficiently light that he was required to do so. These 
actions were not consistent with the procedures established to ensure that the relevant safety constraints were 
enforced. 

Piper Pilot: The pilot misheard the frequency to which the local controller instructed him to switch, and thus was 
unable to communicate with the EWR Class B airspace controller. He did not use the provided electronic traffic 
information system effectively, nor was his visual searching for nearby traffic effective. 

Eurocopter Pilot: This pilot did not use the traffic information system to effectively locate neighboring aircraft. 

Dysfunctional interactions: The communication between TEB ATCT and EWR ATCT did not function as intended. 
The TEB local controller was late in transferring communication between the airplane and EWR ATCT. Because of 
the pilot’s misunderstanding of the frequency, and the TEB local controller’s failure to correct this 
misunderstanding, the EWR Class B airspace controller was unable to contact the pilot. 

Reasons for Inadequate Control Actions and Interactions : The seventh, and final, step taken in the project was to use 
one of the STAMP classifications of causal factors to determine possible reasons for the inadequate control actions 
and dysfunctional interactions happening. The categories examined were incorrect control algorithms, inaccurate 
process models, and coordination. 

Incorrect Control Algorithms: Although the accident involved several failures to follow precisely the existing rules 
and procedures, it also revealed inadequacies within those rules and procedures, which even if they had been 
followed more closely, may not have prevented the accident. For example, the rules specified altitudes to be used 
by aircraft transiting the Hudson River Class B exclusion area, but they did not specify altitudes for aircraft, such as 
sightseeing tour helicopters, operating within the area. Also, procedures recommended, but did not require self- 
announcement over the common traffic advisory frequency. 

Also, the guidance provided to pilots about how to implement the see-and-avoid concept (AC 90-48C, mentioned 
above) was issued in March 1983. Although much of the material remains pertinent today, some of it is outdated. In 
particular it provides no guidance about technological advances in aircraft equipment for traffic awareness, nor does 
it provide specific guidance for air tour operations in high-volume traffic environments. 

The see-and-avoid concept itself has certain limitations as a control algorithm. As noted in the NTSB report, these 
limitations include “a pilot’s ability to perform systematic scans, competing operational demands, environmental 
factors, and blind spots associated with an aircraft’s structure.” Traffic advisory systems are designed to help 
overcome some of these limitations, but these systems have their own limitations. This is particularly true in regards 
to helicopter operations. 

Inaccurate Process Models: Because the relevant control elements considered in this project were all humans, a 
process model is equivalent to a mental model. The investigation revealed that the actions of the Piper pilot were 
likely based on a flawed mental model of the situation. 

The Piper pilot did not anticipate flying through the Hudson River Class B exclusion area. His reasonable 
expectation was that he would be cleared directly into Class B airspace well before reaching the exclusion area. 
Without expecting to enter the Class B exclusion area, he had no reason to be prepared to self-announce his presence 
upon entering the area. Because he asked for continual traffic advisories, and was not told that he would not be 
receiving them, he had every reason to expect that the absence of such advisories meant that there was no traffic in 
the area that he needed to monitor carefully either using his on-board TIS or see-and-avoid scanning techniques. 



The Eurocopter pilot, the TEB local controller, and the EWR Class B airspace controller also had flawed mental 
models: if their mental models had corresponded to reality, which was that a midair collision was imminent, they 
would have taken different actions than they did take. These mental models were not analyzed in depth during the 
project. 

Coordination among multiple controllers: As noted above, the TEB local controller and EWR Class B airspace 
controller did not coordinate effectively, at least partially because the rules and procedures in place at the time of the 
accident were inadequate to ensure this coordination. In particular, the procedures for coordination between TEB 
and EWR did not ensure the timely issuing of a Class B clearance. As a result of the accident and NTSB 
recommendations based on its preliminary investigation into the accident, the coordination procedures were revised 
to correct these deficiencies. Among the changes implemented was moving the common transfer point between 
TEB and EWR, incorporating a standard VFR route for departure aircraft from TEB that would not be requesting 
entry into Class B airspace, and developing a standard Class B transition route that included traffic advisories and 
safety alerts. 


Concluding Remarks 


As noted in the introduction, the two primary objectives for the project described above were (1) to determine 
whether the existing literature on STAMP was sufficient to enable someone to use the model without prior training, 
and (2) to evaluate potential benefits of the model. The first objective was fully achieved. The first author had no 
prior background in accident investigation and analysis techniques, nor did he know anything about STAMP before 
starting the project. Yet, he was able to complete a fairly detailed and insightful analysis during the 10-week 
internship period. Thus, we feel confident in asserting that STAMP appears to be usable without extensive training. 

Evaluating the benefits of STAMP based on the case study is a bit more difficult. As noted above the analysis was 
conducted based on the factual material presented in the NTSB report and related materials. Thus, the project cannot 
be said to have resulted in an independent analysis of the accident. This lack of true independence makes it 
impossible to draw any definite conclusions about the merits of STAMP; however, making two observations does 
seem reasonable. 

Observation one: Thinking in terms of control structures seems to provide a potentially useful perspective. The 
second author had read the NTSB report several times, and attended the Board meeting in which the report was 
presented and adopted. Nevertheless, studying various iterations of the control structure diagrams developed by the 
first author gave him a slightly different perspective than he had possessed before about the complexities and 
subtleties of the interactions involved in the accident. 

Observation two : Differences in style may obscure similarities in results. Proponents of STAMP sometimes draw 
sharp contrasts between it and other accident models and analysis techniques. Two frequently highlighted contrasts 
include STAMP’S concentration on dynamic system models instead of linear chains of events, and STAMP’S 
emphasis on systemic issues instead of blaming operators by simplistic probable cause statements. These contrasts 
are claimed to make STAMP a better, more effective model for accident investigation and analysis than any that are 
currently used (ref. 4). 

A superficial comparison of the STAMP analysis conducted for this project with the official NTSB report may seem 
to provide strong support for these assertions. After all, the NTSB probable cause statement may be said to ‘blame’ 
failures by the TEB local controller and both pilots; although other factors are also ‘blamed.’ If one considers only 
the probable cause statement, one could mistakenly think that the NTSB failed to consider the sorts of systemic 
issues that STAMP emphasizes. But, a careful look at the entire official report shows that systemic and control 
issues were carefully analyzed, and that the primary focus of the NTSB’s recommendations was on addressing those 
issues. Our STAMP analysis did not identify any entirely new factors, although, as noted in observation one, 
STAMP’S emphasis on control structures provided a different perspective from which to view the factors. 

In conclusion, the results of this project suggest that STAMP is a potentially useful addition to the accident 
investigator’s arsenal of ways to think about accidents. More research is needed to determine whether using STAMP 
will necessarily produce results significantly different from, and better than, the results produced by professional 
investigations today. 
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